Each host connected to the Internet has a unique Internet Protocol (IP) address in textual form, translating it to an IP address (e.g., 205.186.173.184, 50.58.79.42, etc.) is a process known as DNS resolution or DNS lookup. Conventionally, there is no way to attribute DNS transactions to a specific user. The reason is simple—the DNS protocol itself was never intended to facilitate user-level visibility of who the transactions occurred from. The only source/user/requestor level information present in a DNS transaction is the source IP address that the request originated from. However there is no direct way to correlate an IP address to a user. Additionally IP addresses can and do change. This challenge is further complicated if a service external to the network wants visibility to attribute users to DNS transactions. The source IP address in that case is often meaningless if NAT (network address translation) is occurring. With NAT multiple users' DNS transactions will be translated to come from a single shared IP address. As a result a source IP address can represent multiple users. It would be advantageous to specify each user to each DNS transaction such as for user-level differentiated policy and reporting with seamless/transparent authentication using a DNS-based system.
Additionally, during DNS resolution, a program that wishes to perform this translation contacts a DNS server that returns the translated IP address. In practice, the entire translation may not occur at a single DNS server; rather, a DNS server contacted initially may recursively call upon other DNS servers to complete the translation. For a more complex Uniform Resource Locator (URL) such as www.site.com/home/products, the crawler component responsible for DNS resolution extracts the host name—in this case www.site.com—and looks up the IP address for the host www.site.com. DNS resolution today takes place in a very static model. A client requests resolution for a given domain name via its configured DNS server, the server recursively searches for that resolution, and then returns the result to the client.
A challenge occurs in that many Internet services today rely on DNS (and the server recursion process) to provide localization of content as well as to optimize content delivery. For example for google.com, the recursion process may return a different IP address for a user located in the U.S. or even for a specific location in the U.S. versus a user in a foreign country. Content is geo-localized or routed to the best destination based on the source IP address of the DNS server that performed the recursion. This is primarily because to localize or optimize content based on DNS alone the only information present beyond the domain name being resolved recursively is the IP address that requested the resolution. As a result to provide the best experience possible (localized or optimized content delivery) DNS servers traditionally needed to be local to the clients that they are serving. Another challenge is how to effectively scale a DNS-policy driven infrastructure that is capable of supporting tens or hundreds of millions of devices. On one hand, it is desired take all DNS traffic from a given device, all the time, to apply policy. On the other the hand, this must manage the load placed that infrastructure when it is adopted at any amount of scale. Having the ability to distribute the load becomes critical.
Finally organizations also provide split horizon/differentiated DNS resolution based on where the client is. For example, the resolution of a particular domain name internal to a network may provide a different IP address than if it originated outside that network. Differentiated resolution can also occur in any application that needs to route traffic based factors other than locality or optimization. As a result, when building a service that is inherently based on DNS, that service either needs to be highly localized and massively distributed or have a way to take into account the need for localized recursion for requested destinations in the form of a policy. Additionally for the DNS service to remain operable it needs to scale elastically and without limit.